Hi! I apologise for the radio silence on this PR. I've recently been exploring Pyodide/WASM support for Zarr again, as we aim to reintroduce Zarr to https://github.com/pyodide/pyodide-recipes. We will utilise that repository in the next release of Pyodide, namely version 0.28, scheduled for release in a few weeks – please see the tracking issue at pyodide/pyodide-recipes#99 for a subset of our remaining work. We currently use Python 3.13, and the first version of Zarr that supports it is v3, which meant that we needed to get this working – we had disabled Zarr due to the use of threads. I've tried to revisit support for Pyodide through the recent commits I've pushed, and I've been able to get it to work.

If I understand correctly, Zarr's inherent threading model in v3 can be bypassed in WebAssembly through the browser's/Node.js's event loop, as demonstrated in my changes to src/zarr/core/sync.py. The only route it disables is zarr.sync, and tests in test_sync.py are skipped as a result. If I understand correctly, zarr.sync is going away anyway with a later version of Zarr.

This PR depends on its sister PR that I created at zarr-developers/numcodecs#529 where we're hoping to add Pyodide/WASM support for numcodecs. All tests have been passing there and it has been ready for further review. Here, I'm temporarily building numcodecs from my PR's branch there, as the version of numcodecs in the Pyodide distribution itself is old does not satisfy the constraint here (>=0.16). I still haven't been able to figure out why the VCS system is not picking up the right version in CI – it looks like a bug where actions/checkout@v4 does not fetch tags and does not perform an unshallow clone when checking out to a directory other than {{ github.workspace }}. Either way, I've temporarily skipped the version check for now so that we can let the tests run till the end.

Hence, while this is obviously not in a mergeable state – I've been able to get several tests passing and Zarr seems to be working well. I believe this PR is ready for review and further inspection, and it should enable us to integrate a portion of this PR as a patch for Pyodide, allowing Zarr to be re-enabled once the idea receives peer review here. A full review can proceed in the meantime as I work through this PR.

In other respects, what I'm finding a bit concerning is the slowness of the test suite in CI. The CI job took 5 hours to run, which seems like an anomaly – in a Pyodide virtual environment on my macOS machine locally, I've been able to consistently run the tests until completion in ~11 minutes on multiple runs, rather than hours. test_set_orthogonal_selection_3d takes 6034 seconds here, which is more than 150x of what it takes outside of CI. Would it make sense to add an additional slow_in_wasm marker so that pytest can ignore the tests shown below?

============================= slowest 10 durations =============================
6034.84s call     tests/test_indexing.py::test_set_orthogonal_selection_3d
4101.22s call     tests/test_properties.py::test_array_creates_implicit_groups
3878.97s call     tests/test_properties.py::test_array_roundtrip
924.30s call     tests/test_properties.py::test_roundtrip_array_metadata_from_store
714.00s call     tests/test_indexing.py::test_set_orthogonal_selection_2d
397.94s call     tests/test_indexing.py::test_set_coordinate_selection_2d
242.29s call     tests/test_indexing.py::test_set_orthogonal_selection_1d
150.35s call     tests/test_indexing.py::test_set_block_selection_2d
121.05s call     tests/test_indexing.py::test_set_block_selection_1d
95.83s call     tests/test_indexing.py::test_get_orthogonal_selection_3d

I've also xfailed some flaky tests arising from Hypothesis, which I haven't been able to figure out the cause for, and marked a Blosc test where I get mismatched arrays (which will need further probing into how Blosc was compiled to WASM) as a known failure case – I hope that is alright!

Out of the two failing tests in the CI job:

• test_array_roundtrip xfails on my local setup on several reruns due to Hypothesis having degraded performance when generating test cases, and it looks like it strict-xpassed here. It is likely a flake, too.
• I had introduced a lenience factor for tests/test_group.py::test_group_members_performance[memory] to accommodate the fact that it takes a little longer to run, likely due to overhead accumulated by running in WASM and the latency coming from the Node.js event loop. The lenience factor/tolerance of 1.1 is apparently good enough for my machine, but we know CI machines are quite unreliable, and the required lenience factor to make it pass here would be 4. I'm open to receiving suggestions about this test. My suggestion would be to rework the test method to test versus multiple group counts—parametrised—and verify that the time taken doesn't scale linearly with the group count (i.e., times should be roughly similar if $O(1)$, later times should be much larger if $O(n)$; and the time ratio should ideally be much less than the linear scaling ratio).

Thank you for your time!